This page last changed on Oct 18, 2004 by mroberts.
- Test-first development. Code without unit tests will not be accepted.
- Refactor mercilessly; however, notify the list before making large, broad-reaching refactorings.
- Small methods (no more than 15 lines). Long methods will be collected and emailed to the list until a refactored solution is found.
- Use guard clauses.
- Write acceptance tests wherever possible.
These standards are ideals, and not necessarily the current state of the code
- No unit-testing of private methods. TDD implies it is unnecessary.
- Don't make methods public just so you can test them (see above)
- Use Constructor Dependency Injection where possible.
- Use Dynamic Mocks for Constructor Dependencies.
- Interface-first design is preferred (i.e. all Constructor Dependencies should be interfaces)
- DefaultXYZ as a name is a smell. What exact type of interface are you implementing?
- Respect the brace style. Curly braces at the start of the line:
public Class Foo
{
public Foo()
{
Console.WriteLine("Hello World!");
}
}
- Use C# naming conventions: methods, properties, classes should all start with upper-case letters.
- Namespaces should be C# style. They should start with 'ThoughtWorks.CruiseControl.XYZ' where XYZ is the Visual Studio Project Name. Sub-namespaces should map to directories where source files are saved.
- One file, one class – unless the inner class is private.
- All member variables should be prefixed with an underscore (ie. _name).
- The ternary operator is fine as long as the conditions are very simple.
- Avoid assignment in conditionals – extract to method instead
- Avoid magic numbers, use a nested enum or an inner class with public const members instead.
- Use spaces after punctuation such as commas and spaces, in accordance with standard written grammar. For example, please include spaces after semi-colons, between equals signs and after keywords
for (int i = 0; i < array.Count; i++):
|